The implementation of a VVoIP system in the local enclave and its connection to external networks degrades the enclave’s perimeter protection due to an inadequate design of the VVoIP boundary with those external networks.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-8328	VVoIP 1005 (GENERAL)	SV-8823r1_rule	EBBD-1 EBBD-2 EBBD-3 ECSC-1	High

Description
VVoIP has the potential to significantly degrade the enclave boundary protection afforded by the required boundary firewall unless the firewall is designed to properly handle VVoIP traffic. The typical firewall used to protect an enclave that supports normal data traffic is not capable of properly handling or supporting real time communications (VVoIP). The following paragraphs will demonstrate this. VVoIP uses a signaling protocol and a media transfer protocol that require both inbound and outbound permissions be set for these protocols in order to provide the capability to place and receive calls to/from endpoints outside the enclave. More specifically, the signaling protocol typically uses one or more static TCP ports that must be open inbound at all times to receive calls. The media protocol; Real-time Transfer Protocol (RTP) and its companion protocol Real-time Transfer Control Protocol (RTCP) utilize randomly assigned UDP ports in the potential range of 1025-65535 with four IP ports required for every bi-directional voice session/call. The number of ports is expanded if video is added. The typical method of supporting VoIP through a standard data firewall is to open (or permit inbound) the signaling IP port(s) and a wide range of UDP ports for the RTP/RTCP media streams. While a typical data firewall can provide some protection from a VoIP implementation if the inbound permit statements are limited to specific limited address ranges (applicable in some situations), this is not possible if calls are to be permitted from any IP address on the Internet or NIPRNet that could be located anywhere in the world. Address segregation for VVoIP is generally not possible since the NIPRNet address space is disjointed (chopped up) and is spread across the overall public Internet (IPv4) address space. To support a worldwide IP enabled DSN, a typical data firewall would need to permit VVoIP signaling and media inbound from the entire registered IPv4 address space. One reason why this is the case is that an ACL developed to limit inbound enclave access to permit only NIPRNet addresses would require many permit statements such that the ACL itself could degrade firewall or router performance. As such, permitting VVoIP traffic across a standard data firewall opens gaping holes in the enclave’s perimeter protection. This is of particular concern when the WAN is the Internet or a DISN service that provides connection to the INTERNET such as the NIPRNet. On the other hand, a standard data firewall poses problems for VVoIP call/session completion if external public addressing is used with internal private (RFC 1918) addressing which requires the firewall to do NAT/NAPT. This is because the VVoIP endpoints need to know the IP address of the other endpoint and they signal their address within the signaling messages. The firewall changes the IP address of the packet during the NAT but does not change it in the signaling message causing a mismatch. The effect is that the call/session cannot be completed. NOTE: If the WAN is a “closed” system where the entire address space of the WAN and connected enclaves is managed by a “single system manager” (as is the case with DISN classified networks) a specific limited and segregated address space can be assigned for all VVoIP devices for use across the entire network. In this case, the risk to the enclave can be limited (although not eliminated) if a standard firewall is used with inbound permit statements that are based on the segregated IP address range. This protection can be further enhanced by limiting the UDP port range. An allowance has been made for such a situation; however, this may change in the future. Based on the above, If VVoIP is to traverse the enclave boundary; the firewall must be VVoIP aware or capable. A VVoIP aware/capable firewall provides the following minimal functions. > Interprets and understands the signaling protocol to determine the UDP ports that are negotiated for the RTP/RTCP media streams. > Dynamically opens the required UDP ports to permit the flow of the media (audio and video). > Performs stateful inspection on the UDP media packets to ensure the packets are part of the active call/session, while dropping all non session packets. > Closes the UDP ports when the end of the call/session is signaled OR after a period of session inactivity. In the event NAT is used across the enclave boundary, the VVoIP aware/capable firewall provides the following NAT functions: > Interprets and understands the signaling protocol to determine the IP addresses that are negotiated between the endpoints and adjusts the signaling messages in accordance with the local NAT/NAPT internal and external addresses. > Performs the NAT/NAPT address changes on the RTP/RTCP media packets as they traverse the boundary. In the event, the VVoIP enclave boundary provides access to and interoperability with a DISN IP based assured service voice service (such as the IP-DSN on NIPRNet), VVoIP aware/capable firewall must provide the following additional functions (Note: these are defined in the UCR): > Provides encryption services for the signaling protocol (AS-SIP uses TLS) > Provides authentication of the source of the signaling protocol packets and drops all unauthenticated packets. > Provides integrity validation of the signaling protocol packets and drops all invalid or modified packets. > Terminates the AS-SIP signaling session and checks the validity of the AS-SIP messages based on content and establishes a new signaling session for the next hop, thus performing an application level inspection of the signaling messages. > Communicates with Call controllers (LSCs and MFSSs) using AS-SIP/TLS > Interprets and understands the AS-SIP signaling protocol to provide the minimal and NAT functions noted above > Supports encrypted RTP/RTSP media streams. That is SRTP/SRTCP > Provides the capability to decrypt the media streams for inspection and recording. This supports monitoring/recording for CALEA and COMSEC monitoring purposes for calls that traverse the enclave boundary. > Performs intrusion and DoS detection with alarm capability for both the signaling and media. > Blocks all non VVoIP traffic whether destined for the VVoIP or data sub-enclaves. NOTE: While RTCP messages could be validated for content and format, the contents of RTP packets cannot due to the random nature of the audio and video data being transmitted. Delaying the RTCP packets for inspection or the SRTCP messages for decryption and inspection while passing the RTP/SRTP packets would cause disruption in the media flow and thereby negatively affect its quality. Additionally, the delay of the SRTP packets for decryption and inspection would have similar effects. Thus intrusion detection based on the media streams is almost impossible since attack profiles are generally unavailable. Based on this and to improve worldwide voice quality, the DSN/RTS PMO and the RTS WG has determined that the SRTP/SRTCP streams will be passed by the VVoIP firewall without inspecting the encrypted contents of the packets. NOTE: The VVoIP aware/capable firewall discussed here defines a set of functions that are unique to a VVoIP which are different from the set of functions required for data firewalls. The functions for data firewalls are defined in the Network Infrastructure STIG. While typically a single firewall will not be capable of supporting both sets of functions (which means a separate VVoIP firewall is needed in parallel to the data firewall) this requirement does not mean that a dedicated VVoIP firewall must be implemented in the event a single firewall is capable of implementing both sets of functions simultaneously. The primary task of the data firewall function is to protect the entire enclave. In doing so, it must perform its normal function of protecting the data sub-enclave while also blocking all VVoIP traffic destined for it via the data firewall. An exception could be made for this on a case by case basis if permissions are limited in scope as would be the case for VTC. All data traffic/protocols destined for the VVoIP sub-enclave must also be blocked unless specifically authorized to meet a mission need. Such a mission need might be for remote management of the VVoIP system from a NOC or user-to-site VPN, however, this traffic must would be routed to the VVoIP management VLAN(s) and not the VVoIP production VLANs. An additional consideration for passing VoIP across an enclave boundary is when there are different vendor’s VoIP systems deployed within the different enclaves connected to the WAN, and the various vendor’s systems are not interoperable or do not provide assured service outside the enclave, or the WAN cannot support QoS and assured service. In this case, interoperability and assured service must be preserved across the DSN or DISN voice network, whether traditional TDM or VoIP. Therefore, the VoIP system must connect to other enclaves via a traditional TDM based long haul network. Such a connection is made using a media gateway. Therefore, if the enclave VoIP system is not compatible with the IP enabled DSN as defined in the UCR thereby providing interoperability and assured service end-to-end across the DISN voice network, the system must employ a media gateway and connect to a traditional DSN switch. Additionally, unless specific requirements (discussed later) are met, all connections to the PSTN must be via a media gateway and an appropriate trunk (PRI or CAS).

Description

VVoIP has the potential to significantly degrade the enclave boundary protection afforded by the required boundary firewall unless the firewall is designed to properly handle VVoIP traffic. The typical firewall used to protect an enclave that supports normal data traffic is not capable of properly handling or supporting real time communications (VVoIP). The following paragraphs will demonstrate this. VVoIP uses a signaling protocol and a media transfer protocol that require both inbound and outbound permissions be set for these protocols in order to provide the capability to place and receive calls to/from endpoints outside the enclave. More specifically, the signaling protocol typically uses one or more static TCP ports that must be open inbound at all times to receive calls. The media protocol; Real-time Transfer Protocol (RTP) and its companion protocol Real-time Transfer Control Protocol (RTCP) utilize randomly assigned UDP ports in the potential range of 1025-65535 with four IP ports required for every bi-directional voice session/call. The number of ports is expanded if video is added. The typical method of supporting VoIP through a standard data firewall is to open (or permit inbound) the signaling IP port(s) and a wide range of UDP ports for the RTP/RTCP media streams. While a typical data firewall can provide some protection from a VoIP implementation if the inbound permit statements are limited to specific limited address ranges (applicable in some situations), this is not possible if calls are to be permitted from any IP address on the Internet or NIPRNet that could be located anywhere in the world. Address segregation for VVoIP is generally not possible since the NIPRNet address space is disjointed (chopped up) and is spread across the overall public Internet (IPv4) address space. To support a worldwide IP enabled DSN, a typical data firewall would need to permit VVoIP signaling and media inbound from the entire registered IPv4 address space. One reason why this is the case is that an ACL developed to limit inbound enclave access to permit only NIPRNet addresses would require many permit statements such that the ACL itself could degrade firewall or router performance. As such, permitting VVoIP traffic across a standard data firewall opens gaping holes in the enclave’s perimeter protection. This is of particular concern when the WAN is the Internet or a DISN service that provides connection to the INTERNET such as the NIPRNet. On the other hand, a standard data firewall poses problems for VVoIP call/session completion if external public addressing is used with internal private (RFC 1918) addressing which requires the firewall to do NAT/NAPT. This is because the VVoIP endpoints need to know the IP address of the other endpoint and they signal their address within the signaling messages. The firewall changes the IP address of the packet during the NAT but does not change it in the signaling message causing a mismatch. The effect is that the call/session cannot be completed. NOTE: If the WAN is a “closed” system where the entire address space of the WAN and connected enclaves is managed by a “single system manager” (as is the case with DISN classified networks) a specific limited and segregated address space can be assigned for all VVoIP devices for use across the entire network. In this case, the risk to the enclave can be limited (although not eliminated) if a standard firewall is used with inbound permit statements that are based on the segregated IP address range. This protection can be further enhanced by limiting the UDP port range. An allowance has been made for such a situation; however, this may change in the future. Based on the above, If VVoIP is to traverse the enclave boundary; the firewall must be VVoIP aware or capable. A VVoIP aware/capable firewall provides the following minimal functions. > Interprets and understands the signaling protocol to determine the UDP ports that are negotiated for the RTP/RTCP media streams. > Dynamically opens the required UDP ports to permit the flow of the media (audio and video). > Performs stateful inspection on the UDP media packets to ensure the packets are part of the active call/session, while dropping all non session packets. > Closes the UDP ports when the end of the call/session is signaled OR after a period of session inactivity. In the event NAT is used across the enclave boundary, the VVoIP aware/capable firewall provides the following NAT functions: > Interprets and understands the signaling protocol to determine the IP addresses that are negotiated between the endpoints and adjusts the signaling messages in accordance with the local NAT/NAPT internal and external addresses. > Performs the NAT/NAPT address changes on the RTP/RTCP media packets as they traverse the boundary. In the event, the VVoIP enclave boundary provides access to and interoperability with a DISN IP based assured service voice service (such as the IP-DSN on NIPRNet), VVoIP aware/capable firewall must provide the following additional functions (Note: these are defined in the UCR): > Provides encryption services for the signaling protocol (AS-SIP uses TLS) > Provides authentication of the source of the signaling protocol packets and drops all unauthenticated packets. > Provides integrity validation of the signaling protocol packets and drops all invalid or modified packets. > Terminates the AS-SIP signaling session and checks the validity of the AS-SIP messages based on content and establishes a new signaling session for the next hop, thus performing an application level inspection of the signaling messages. > Communicates with Call controllers (LSCs and MFSSs) using AS-SIP/TLS > Interprets and understands the AS-SIP signaling protocol to provide the minimal and NAT functions noted above > Supports encrypted RTP/RTSP media streams. That is SRTP/SRTCP > Provides the capability to decrypt the media streams for inspection and recording. This supports monitoring/recording for CALEA and COMSEC monitoring purposes for calls that traverse the enclave boundary. > Performs intrusion and DoS detection with alarm capability for both the signaling and media. > Blocks all non VVoIP traffic whether destined for the VVoIP or data sub-enclaves. NOTE: While RTCP messages could be validated for content and format, the contents of RTP packets cannot due to the random nature of the audio and video data being transmitted. Delaying the RTCP packets for inspection or the SRTCP messages for decryption and inspection while passing the RTP/SRTP packets would cause disruption in the media flow and thereby negatively affect its quality. Additionally, the delay of the SRTP packets for decryption and inspection would have similar effects. Thus intrusion detection based on the media streams is almost impossible since attack profiles are generally unavailable. Based on this and to improve worldwide voice quality, the DSN/RTS PMO and the RTS WG has determined that the SRTP/SRTCP streams will be passed by the VVoIP firewall without inspecting the encrypted contents of the packets. NOTE: The VVoIP aware/capable firewall discussed here defines a set of functions that are unique to a VVoIP which are different from the set of functions required for data firewalls. The functions for data firewalls are defined in the Network Infrastructure STIG. While typically a single firewall will not be capable of supporting both sets of functions (which means a separate VVoIP firewall is needed in parallel to the data firewall) this requirement does not mean that a dedicated VVoIP firewall must be implemented in the event a single firewall is capable of implementing both sets of functions simultaneously. The primary task of the data firewall function is to protect the entire enclave. In doing so, it must perform its normal function of protecting the data sub-enclave while also blocking all VVoIP traffic destined for it via the data firewall. An exception could be made for this on a case by case basis if permissions are limited in scope as would be the case for VTC. All data traffic/protocols destined for the VVoIP sub-enclave must also be blocked unless specifically authorized to meet a mission need. Such a mission need might be for remote management of the VVoIP system from a NOC or user-to-site VPN, however, this traffic must would be routed to the VVoIP management VLAN(s) and not the VVoIP production VLANs. An additional consideration for passing VoIP across an enclave boundary is when there are different vendor’s VoIP systems deployed within the different enclaves connected to the WAN, and the various vendor’s systems are not interoperable or do not provide assured service outside the enclave, or the WAN cannot support QoS and assured service. In this case, interoperability and assured service must be preserved across the DSN or DISN voice network, whether traditional TDM or VoIP. Therefore, the VoIP system must connect to other enclaves via a traditional TDM based long haul network. Such a connection is made using a media gateway. Therefore, if the enclave VoIP system is not compatible with the IP enabled DSN as defined in the UCR thereby providing interoperability and assured service end-to-end across the DISN voice network, the system must employ a media gateway and connect to a traditional DSN switch. Additionally, unless specific requirements (discussed later) are met, all connections to the PSTN must be via a media gateway and an appropriate trunk (PRI or CAS).

STIG	Date
Voice/Video Services Policy STIG	2014-04-07

Details

Check Text ( C-23854r1_chk )
Interview the IAO to confirm compliance with the following requirement: In the event a VVoIP system is deployed/implemented within the local enclave (LAN/CAN) AND the enclave accesses or connects to external networks (for example, another LAN or a WAN), ensure the enclave’s connection to the external network is designed to maintain the required enclave boundary protection for the data, VVoIP, and VTCoIP sub-enclaves (internal VLANS); maintains VLAN separation within the LAN/CAN; as well as support assured service interoperability between different vendor’s VVoIP systems implemented in different enclaves. NOTE: Connection to a WAN generally means a connection to a DISN service such as the NIPRNet or SIPRNet but might also refer to the Internet. Determine if the local enclave (LAN/CAN) connects to a WAN or if it reaches the WAN via a connection with another LAN/CAN/enclave as might be the case for a tenant of a larger BCPS (subtended enclave). If so, determine if the enclave’s boundary protection is designed/implemented to protect the VVoIP endpoints and infrastructure as well as the data enclave. > The data firewall function provides protection for the VVoIP sub-enclave (VLANs) and infrastructure as follows: >> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC >> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs. >> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations (local or in a remote NOC). >> Inspects (along with the IDS) all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose.) > The VVoIP firewall function Required if VVoIP is permitted on the WAN)provides protection for the VVoIP sub-enclave and the data sub-enclave as follows: >> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs >> Inspects all VVoIP traffic destined for the VVoIP production VLANs. >> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication of this is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html. > In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system). NOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements. NOTE: The following is here for informational purposes and is discussed in another requirement. > In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor’s VVoIP system does not directly interoperate with other vendor’s VVoIP systems AND the VVoIP system is connected to the DSN, the connection is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk).

Check Text ( C-23854r1_chk )

Interview the IAO to confirm compliance with the following requirement:

In the event a VVoIP system is deployed/implemented within the local enclave (LAN/CAN) AND the enclave accesses or connects to external networks (for example, another LAN or a WAN), ensure the enclave’s connection to the external network is designed to maintain the required enclave boundary protection for the data, VVoIP, and VTCoIP sub-enclaves (internal VLANS); maintains VLAN separation within the LAN/CAN; as well as support assured service interoperability between different vendor’s VVoIP systems implemented in different enclaves.

NOTE: Connection to a WAN generally means a connection to a DISN service such as the NIPRNet or SIPRNet but might also refer to the Internet.

Determine if the local enclave (LAN/CAN) connects to a WAN or if it reaches the WAN via a connection with another LAN/CAN/enclave as might be the case for a tenant of a larger BCPS (subtended enclave). If so, determine if the enclave’s boundary protection is designed/implemented to protect the VVoIP endpoints and infrastructure as well as the data enclave.

> The data firewall function provides protection for the VVoIP sub-enclave (VLANs) and infrastructure as follows:
>> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC
>> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs.
>> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations (local or in a remote NOC).
>> Inspects (along with the IDS) all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose.)

> The VVoIP firewall function Required if VVoIP is permitted on the WAN)provides protection for the VVoIP sub-enclave and the data sub-enclave as follows:
>> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs
>> Inspects all VVoIP traffic destined for the VVoIP production VLANs.
>> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication of this is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html.

> In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system).

NOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements.

NOTE: The following is here for informational purposes and is discussed in another requirement.

> In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor’s VVoIP system does not directly interoperate with other vendor’s VVoIP systems AND the VVoIP system is connected to the DSN, the connection is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk).

Fix Text (F-20286r1_fix)
In the event a VVoIP/UC system is deployed/implemented within the enclave AND the enclave accesses external networks, ensure the enclave’s connection to external networks is designed to maintain the required enclave boundary protection for both the data and voice/video sub-enclaves as well as separation within the LAN and to support interoperability between different vendor’s VVoIP/UC systems implemented in different enclaves. Design and implement the boundary protection to provide for the following: > The data firewall function provides protection for the VVoIP sub-enclave and infrastructure as follows: >> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols, etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC >> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs. >> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations. >> Inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose). The network IDS inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose). > The VVoIP firewall function provides protection for the VVoIP sub-enclave and the data sub-enclave as follows: >> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs. >> Inspects all VVoIP destined for the VVoIP production VLANs. >> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html. > In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor’s VVoIP system does not directly interoperate with other vendor’s VVoIP systems AND the VVoIP system is connected to the DSN; the connection to the DSN is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk) NOTE: this is covered under another requirement. > In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system). NOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements. In the event the enclave is part of a “closed” DISN classified network or an organizational intranet AND the PMO for the “closed” DISN classified network or an organizational intranet has designated a segregated IP address range for use by VVoIP systems, AND There is no dedicated VVoIP firewall function (as defined by the UCR) implemented, configure the system for the following: >> Utilizes the PMO designated VVoIP address space for the VVoIP system within the enclave. >> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on the PMO designated VVoIP address space. >> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on a limited range of UDP ports as needed for the particular vendor’s system implemented. NOTE: in the event the enclave is part of an organizational intranet, and there is no firewall at the local enclave perimeter, configure the perimeter/premise router to provide the required filtering and routing along with ensuring all inbound and outbound traffic enters the required dedicated circuit or encrypted VPN. Specific network requirements for organizational intranet design and implementation is beyond the scope of this document.

Fix Text (F-20286r1_fix)

In the event a VVoIP/UC system is deployed/implemented within the enclave AND the enclave accesses external networks, ensure the enclave’s connection to external networks is designed to maintain the required enclave boundary protection for both the data and voice/video sub-enclaves as well as separation within the LAN and to support interoperability between different vendor’s VVoIP/UC systems implemented in different enclaves.

Design and implement the boundary protection to provide for the following:

> The data firewall function provides protection for the VVoIP sub-enclave and infrastructure as follows:
>> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols, etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC
>> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs.
>> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations.
>> Inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose).

The network IDS inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose).

> The VVoIP firewall function provides protection for the VVoIP sub-enclave and the data sub-enclave as follows:
>> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs.
>> Inspects all VVoIP destined for the VVoIP production VLANs.
>> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html.

> In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor’s VVoIP system does not directly interoperate with other vendor’s VVoIP systems AND the VVoIP system is connected to the DSN; the connection to the DSN is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk) NOTE: this is covered under another requirement.

> In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system).

NOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements.

In the event the enclave is part of a “closed” DISN classified network or an organizational intranet AND the PMO for the “closed” DISN classified network or an organizational intranet has designated a segregated IP address range for use by VVoIP systems, AND There is no dedicated VVoIP firewall function (as defined by the UCR) implemented, configure the system for the following:
>> Utilizes the PMO designated VVoIP address space for the VVoIP system within the enclave.
>> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on the PMO designated VVoIP address space.
>> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on a limited range of UDP ports as needed for the particular vendor’s system implemented.

NOTE: in the event the enclave is part of an organizational intranet, and there is no firewall at the local enclave perimeter, configure the perimeter/premise router to provide the required filtering and routing along with ensuring all inbound and outbound traffic enters the required dedicated circuit or encrypted VPN. Specific network requirements for organizational intranet design and implementation is beyond the scope of this document.